home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 488 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.9 KB

  1. Path: engnews1.Eng.Sun.COM!taumet!clamage
  2. From: "Paul D. DeRocco" <pderocco@ix.netcom.com>
  3. Newsgroups: comp.std.c++
  4. Subject: Conflicting purposes of exception spec
  5. Date: 18 Feb 1996 02:14:44 GMT
  6. Organization: ?
  7. Approved: clamage@eng.sun.com (comp.std.c++)
  8. Message-ID: <3125C082.2946@ix.netcom.com>
  9. NNTP-Posting-Host: taumet.eng.sun.com
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.0b6a (Win95; I)
  14. Content-Length: 3190
  15. Originator: clamage@taumet
  16.  
  17. It occurs to me that exception specifications, at least empty ones, 
  18. have two possible purposes, and that they conflict in a sense. One is 
  19. to inform the compiler that exceptions actually won't occur, and the 
  20. other is to trap any exceptions that the programmer didn't think would 
  21. occur but wasn't sure about. The former is in the category of an 
  22. optimization hint, like the "register" keyword, while the latter is a 
  23. debugging aid, like an assertion.
  24.  
  25. An empty exception specifier can be a significant aid to optimizing 
  26. the caller of a function. If the caller has a local object whose class 
  27. has a destructor, it needs to set up an exception context to guarantee 
  28. that the destructor is called even if an exception is thrown. If the 
  29. body of the function contains no function calls and no throw 
  30. statements, then it can optimize out the exception context. In theory, 
  31. it can also optimize it out when there are function calls, as long as 
  32. they all have throw() in their declarations.
  33.  
  34. So consider a simple function that I _know_ won't throw an exception:
  35.  
  36.     int sumsq(int a, int b) { return a * a + b * b; }
  37.  
  38. Do I put a throw() clause on it or not? If the compiler uses throw() 
  39. only as an optimization hint to the caller, then I most definitely 
  40. _do_ want to use it. If, on the other hand, the compiler treats 
  41. throw() as a command to add code to prevent any exceptions from 
  42. propagating out of the function, then I most definitely _don't_ want 
  43. to use it. If I guess wrong about the interpretation, I've bought 
  44. myself nothing, and cost myself something. And unless it's spelled out 
  45. in the language definition, I can't make _either_ choice without 
  46. knowing that it won't ever be compiled with a compiler that was 
  47. designed with the opposite choice in mind.
  48.  
  49. When non-empty exception specifiers are present, things are a bit 
  50. simpler, because such a construct isn't particularly useful as an 
  51. optimization hint. When compiling the caller of such a function, an 
  52. exception context is needed to guarantee destructor cleanup if _any_ 
  53. exception can be thrown, even if it is a limited set. About the only 
  54. situation where a non-empty exception specifier can aid optimization 
  55. is if a try block contains only calls to functions that can throw 
  56. exceptions that aren't mentioned in the catch clauses. But in real 
  57. life, one doesn't try to catch exceptions unless they can actually 
  58. occur.
  59.  
  60. This suggests that the use of an exception specifier as an assertion 
  61. is the "correct" interpretation. But the use of an empty specifier as 
  62. an optimization hint is potentially useful, so I propose an 
  63. alternative. Let throw() intercept all exceptions and turn them into 
  64. unexpected(), but use throw(void) to mean that the function really 
  65. doesn't throw any exceptions.
  66.  
  67. So what should happen if a function declared with throw(void) actually 
  68. throws an exception? Consider it "ill-formed", and let it do whatever 
  69. it likes, including unwinding the stack and missing destructors. This 
  70. would certainly be a bug, but there are entire categories of functions 
  71. that the programmer can be assured will never throw exceptions, 
  72. including just about the entire C string library.
  73.  
  74. -- 
  75.  
  76. Ciao,
  77. Paul D. DeRocco
  78.  
  79. [ To submit articles: Try just posting with your newsreader.  If that fails,
  80.               use mailto:std-c++@ncar.ucar.edu
  81.   FAQ:    http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  82.   Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  83.   Comments? mailto:std-c++-request@ncar.ucar.edu
  84. ]
  85.